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(57) Abstract: A system for implementing a real-time distributed, hierarchical database uses a proxiable protocol. The system 
includes a first proxy server for receiving a first proxiable protocol message from a first network element. The first proxy server 
performs a first database lookup based on information contained in the first message. If the first proxy server does not obtain the 
requested information, the first proxy server formulates a second proxiable protocol message and forwards the message to a second 
proxy server. A second proxy server receives the second message and performs a second database lookup based on information 
contained in the second message. The second proxy server sends the results from the second database lookup to the first proxy server 
^ and the first proxy server forwards the results to the database user. 
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Description 

METHODS AND SYSTEMS FOR IMPLEMENTING A REAL-TIME, 
DISTRIBUTED, HIERARCHICAL DATABASE USING A PROXIABLE 
5 PROTOCOL 



Technical Field 

The present invention relates to methods and systems for 
implementing a real-time, distributed, hierarchical database. More 
10 particularly, the present invention relates to methods and systems for 
implementing a real-time, distributed, hierarchical database using a proxiable 
protocol. 

Field of the Invention 

1 5 Classical high performance telephony data structures, such as home 

location registers (HLRs), number portability databases, visitor location 
registers (VLRs), and other subscriber-services-related data structures 
require reliable, real-time access databases. Existing data structures rely on 
large centralized databases implemented in fault-tolerant computing 

20 platforms. Implementing large data structures results in costly, inflexible 
products, and network architectures. 

Figure 1 illustrates a conventional centralized database architecture. 
In Figure 1, a subscriber might desire to make a call to another subscriber 



CONFIRMATION COW 



WO 01/61529 -2- PCT/IB01/00185 

whose number has been ported from one carrier to another carrier. When 
the subscriber dials the number using end user device 100, which can be a 
public switched telephone network (PSTN) terminal, the dialed digits are 
communicated to service switching point (SSP) 102. SSP 102 is a switch at 
5 the calling subscriber's end office that sets up a call with a called party 
through the called party's end office. SSP 102 examines the dialed digits 
and determines that the number has been ported. Accordingly, SSP 102 
formulates a transaction capabilities application part (TCAP) query and 
addresses the query to service control point (SCP) 104. The TCAP query 
10 passes through signal transfer point (STP) 106, which routes the query to 
SCP 104. SCP 104 includes a centralized database containing contact 
numbers corresponding to ported numbers. SCP 104 performs a database 
lookup using the dialed digits and determines a contact number 
corresponding to the ported number. SCP 104 sends the contact number to 
15 SSP 102 through STP 106 in a TCAP response. SSP 102 then sends a call 
setup message to the end office corresponding to the contact number in 
order to establish a call. 

One problem with the centralized database architecture illustrated in 
Figure 1 is that the centralized database in SCP 104 is required to contain 
20 entries for all ported numbers. Large database structures cannot be 
economically implemented by SCP 104. For example, a database can 
require 20 million records for number portability or other service. In order to 
provide a real-time response, e.g., 5 milliseconds or less, the entire 
database is required to be stored in dynamic random access memory (RAM) 
25 of a central processing unit (CPU) engine. The amount of RAM required to 
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store 20 million database records greatly increases the cost of a centralized 
database. For example, 1 Gigabyte of RAM can be required to store 5 
million subscriber database records. Current technology only allows 1 
Gigabyte of RAM to be present on a single Versa Module Europa (VME) bus 
5 board. As a result, multiple VME bus boards with multiple processors are 
required to implement a database of 20 million customer records. Similar 
memory limitations exist in other board technologies such as Compact PCI. 
Such memory and processing requirements are cost-prohibitive for a single 
SCP database. What is needed is a real-time, distributed, hierarchical 

10 database in which database records are distributed across multiple physical 
machines located in different locations. Such a database preferably appears 
as a single database to the database user so that no modifications are 
required to existing telephony equipment, such as end office switches and 
gateways that access the databases. Accordingly, there exists a need for 

15 novel methods and systems for implementing a real-time, distributed, 
hierarchical database in a manner that is transparent to the database user. 



Description of the Invention 
The present invention provides novel methods and systems for 
20 implementing a real-time, distributed, hierarchical database using a proxiable 
protocol. As used herein, the phrase "proxiable protocol" refers to any 
protocol used to send call signaling messages over an IP network in which 
one entity can act as a proxy for another entity in performing a desired 
function. For example, if one entity is unable to respond to a request from a 
25 telephony device, that entity can proxy the request by sending a second 
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request to another entity that is capable of responding. The second request 
includes all of the information in the first request, but specifies that the 
response to the second request is to be sent to the first entity, rather than 
the original requester. When the first entity receives the response, the first 
5 entity responds to the requester as if the first entity had obtained the data. 
In this manner, the number of entities can be increased arbitrarily and 
transparently to the requester. 

One example of a proxiable protocol is the session initiation protocol 
(SIP), as described in Internet Engineering Task Force (IETF) Request for 
10 Comments (RFC) 2543: Session Initiation Protocol, March 1999, the 
disclosure of which is incorporated herein by reference in its entirety. SIP is 
an application layer control protocol that is conventionally used to establish, 
modify, and terminate multimedia sessions or calls. SIP provides proxiable 
messages used to perform call setup, modification, and termination 
15 functions. For example, one SIP message used to perform call setup 
functions is the INVITE message. The INVITE message is conventionally 
used to invite telephony devices to participate in a media stream 
communication, such as a voice communication, a data communication, a 
video communication, or any combination thereof. The INVITE message 
20 includes a session description protocol (SDP) portion that is used by end 
user devices to exchange media capabilities and other information. One 
entity that formulates and processes INVITE messages, as well as other SIP 
messages, is referred to as a proxy server. As defined in the SIP protocol, a 
proxy server is an entity that is capable of acting as a proxy or agent for 
25 another entity. For example, a proxy server can receive a request, interpret 
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the request, and formulate a new request on behalf of the original requester 
Thus, a SJP proxy server is capable of proxying INVITE messages for 
entities, such as SIP clients and other proxy servers functioning as SIP 
clients. Each proxy server in the chain of proxy servers includes its own via 
5 header in the INVITE message. The via headers specify a return path for 
the response that is the same as the request path. According to one aspect 
of the present invention, this proxying and retun>path specifying capability of 
SIP is utilized in a novel way to implement a real-time, distributed, 
hierarchical database. 

10 The present invention is not limited to SIP proxy servers. Any suitable 

proxy server that is capable of proxying requests for other entities and 
specifying a return path is intended to be within the scope of the invention. 

Embodiments of a real-time, distributed, hierarchical database 
described below can be implemented in hardware, software, or a 

15 combination of hardware and software. Accordingly, it is understood that 
embodiments of the present invention can be implemented as computer- 
executable instructions embodied in a computer-readable medium for 
performing the steps described below for implementing a real-time, 
distributed, hierarchical database. Exemplary computer-readable media 

20 suitable for use with the present invention include magnetic and optical disk 
storage devices and electrical storage devices, such as chip memory 
devices. 

Accordingly, it is an object of the present invention to provide novel 
methods and systems for implementing a real-time, distributed, hierarchical 
25 database using a proxiable protocol. 
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An object of the invention having been stated hereinabove and which 
is achieved in whole or in part by the present invention, other objects will be 
evident as the description proceeds, when taken in connection with the 
accompanying drawings as best described hereinbelow. 

5 

Brief Description of the Drawings 
A description of the embodiments of the present invention will now 
proceed with reference to the accompanying drawings of which: 

Figure 1 is a block diagram of a conventional telephone network 
'10 utilizing a centralized database; 

Figure 2 is block diagram of a system for implementing a real-time, 
distributed, hierarchical database according to an embodiment of the present 
invention; 

Figure 3 is a call flow diagram illustrating the operation of a real-time, 
15 distributed, hierarchical number portability database according to an 
embodiment of the present invention; 

Figure 4 illustrates an example of a number portability database that 
can be included in a proxy server according to an embodiment of the present 
invention; 

20 Figure 5 illustrates an example of a system for implementing a real- 

time, distributed, hierarchical database according to yet another embodiment 
of the present invention; and 

Figure 6 is a flow chart illustrating exemplary steps that can be 
performed by a proxy server in providing a default response to an INVITE 

25 message according to an embodiment of the present invention. 
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Detailed Description of the invention 
Figure 2 illustrates a system for implementing a real-time, distributed, 
hierarchical database using a proxiable protocol according to an 
embodiment of the present invention. The entities illustrated in Figure 2 
5 utilize SIP messages to implement a real-time, distributed, hierarchical 
database. However, the present invention is not limited to using SIP 
messages. The use of any proxiable protocol to implement a real-time, 
distributed, hierarchical database is intended to be within the scope of the 
invention. 

10 In Figure 2, an end user device 200 communicates with other end 

user devices through service switching point (SSP) 202. End user device 
200 can be any suitable end user telephony device, such as a stationary 
PSTN terminal or a mobile telephone handset. SSP 202 is an end office 
switch for setting up calls between end users. 

15 SS7/IP gateway 204 connects SSP 202 to IP network 206. For 

example, SS7/IP gateway can include an SS7-compatibIe interface for 
communicating with SS7 nodes and an IP-compatible interface for 
communicating with IP nodes. One particular SS7 capability that gateway 
204 preferably possesses is the ability to recognize TCAP queries and route 

20 the TCAP queries to a database for obtaining a TCAP response. SS7 TCAP 
queries can be recognized through analyzing the service information octet 
(SIO) field in an SS7 MSU. However, according to the present embodiment, 
rather than routing TCAP queries to a centralized SCP database, gateway 
204 formulates a proxiable protocol message and sends that message to 

25 proxy server 208 over IP network 206. 
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Proxy server 208 can be a SIP proxy server that implements the first 
level of a database hierarchy. For example, proxy server 208 can include a 
database that stores records containing the requested information for some 
subscribers and records containing pointers to other databases for other 
5 subscribers. The database accessed by proxy server 208 can also include 
default response information when a lookup fails to produce a record that 
matches data requested in a query. 

In addition, proxy server 208 can receive messages from gateway 
204 and perform a first database lookup based on information contained in 
10 the first message. As used herein, the phrase ^database lookup" is intended 
to include a lookup in a database of records stored in computer memory or 
equivalent logical processing where desired output information is determined 
from input information. If proxy server 208 has the requested information, 
proxy server 208 can respond to the message from gateway 204 by sending 
15 a response containing the results of the lookup to gateway 204. However, 
proxy server 208 might not have the requested information in its local 
database. In this case, results from the first database lookup can include the 
location of a second database where the desired information is located. 
Proxy server 208 then proxies the first message, formulates a second 
20 proxiable protocol message, and sends the second message to another 
proxy server that contains the requested information or the address of 
another server that includes the requested information. For example, proxy 
server 208 can send the second message to proxy server 210 that has 
access to a subscriber database (not shown) containing the requested 
25 subscriber information. In a preferred embodiment, the second message 
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includes return route information so that proxy server 210 will return a 
response to proxy server 208. If proxy server 210 has the desired 
information, proxy server 210 responds to proxy server 208 with the desired 
information. Proxy server 208 sends the information to gateway 204. 
5 Gateway 204 extracts the information and communicates the information to 
SSP 202. 

Because proxy servers according to the present embodiment are 
capable of proxying requests from other entities, including other proxy 
servers, a real-time, distributed, hierarchical database can be implemented 

10 transparently to gateway 204. In addition, the number of levels in the 
database can be arbitrarily increased, simply by adding additional proxy 
servers. The following example illustrates the use of the distributed 
hierarchy illustrated in Figure 2 in responding to a number portability query 
from SSP 202. 

15 Number Portability Example 

Figure 3 is a call flow diagram illustrating an exemplary message flow 
between an SS7/IP gateway and proxy servers implementing a real-time, 
distributed number portability database according to an embodiment of the 
present invention. In line 1 of the call flow diagram, SSP 202 transmits a 

20 TCAP query to SS7/IP gateway 204 requesting information relating to a 
ported number. The method for formulating a TCAP query is known to 
persons of ordinary skill in the telecommunications art and is not essential to 
explaining the present invention. Hence a detailed description of the TCAP 
protocol is not explained herein. What is important for purposes of 
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explaining the present embodiment is that the TCAP query requests 
information regarding a ported number. 

In response to receiving the TCAP query, rather than forwarding the 
query to a SCP, SS7/IP gateway 204 formulates an INVITE message based 
5 on information continued in the TCAP query, in line 2 of the call flow 
diagram, SS7/IP gateway 204 transmits an INVITE message to proxy server 
208. An example of such an INVITE message is as follows: 

1 INVITE 

2 sip:+46706662326@47. 1 1 4. 1 77.55:50002;user=phoneSIP/.0 
10 3 v: SIP/2.0/UDP 47.114.178.11:50001 

4 t: tel:+46706662326 

5 t sip:+705990096@47.1 14.178.1 1:50001 

6 i: a700ff@47.1 14.1 78.1 1:50001 

7 CSeq: 1 INVITE 

15 

In the INVITE message example, line numbers are included on the 
left hand side of each line in the message to facilitate a description of the 
fields in the message. It is understood that these line numbers are included 
for illustration purposes only and are not part of an actual SIP message. It is 

20 also understood that fields other than those illustrated can be included in the 
SIP message without departing from the scope of the invention. In line 1, 
"INVITE" is a method token that identifies the message as an INVITE 
message. In line 2, the number "4670662326" is the called party number for 
which a contact number is sought. Also in line 2, the number 

25 "47.1 14.177.55:50002" is the IP address and port number of proxy sever 208 
to which the "INVITE" message is being sent. Line 3 of the SIP message is 
the via header. The via header identifies the return path for responding to 
the SIP message. In the example SIP message illustrated above, the return 
path is identified by the IP address and port number of signaling gateway 
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204 for receiving SIP messages. In the illustrated example, the IP address 
is 47.114.178.11 and the port number is 50001. In an alternative 
embodiment, the via header can contain an asynchronous transfer mode 
(ATM) address as the return routing information. Line 4 of the SIP message 
5 contains the "to" field, which includes the called number. Line 5 of the SIP 
message is the "from" field which contains the calling party number as well 
as the IP address and port number of signaling gateway 204 from which the 
SIP message originated. Line 6 of the SIP message contains a call 
identifier, which is used by SIP devices which is used to identify messages 

10 associated with a call. Line 7 of the SIP message contains a call sequence 
number which is used to identify the sequence of the message within a call. 

In response to receiving the INVITE message, proxy server 208 
searches at its database and determines that it does not have the data being 
requested. Accordingly, in line 3 of the call flow diagram, proxy server 208 

15 formulates and sends a TRYING message to the originator of the query, i.e. 
to SS7/IP gateway 204. An example of such a TRYING message is as 
follows: 



message. Line 1 also contains the SIP version number. Line 2 contains the 
via header for the TRYING message. In the example SIP message, the via 
header includes the IP address and port number of proxy server 208. Line 3 



20 



1 

2 
3 
4 
5 
6 



SIP/2.0 100 Trying 

v: SIP/2.0/UDP 47.114.178.11:50001 

t: tel:+46706662326 

f: sip:+705990096@47.1 14.178.1 1:50001 
i: a700ff@47.1 14.178.1 1:50001 
CSeq: 1 INVITE 



25 



Line 1 of the SIP message identifies the message as a TRYING 
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of the SIP message is the "to" field, which contains the called number. Line 
4 of the SIP message as the "from" field which contains the calling party 
number as well as the IP address and port number on signaling gateway 204 
for receiving SIP messages. Line 5 of the SIP message is the call identifier, 
5 and line 6 of the SIP message is the call sequence number, as previously 
described. 

In line 4 of the call flow diagram, proxy server 208 forwards (proxies) 
the INVITE message, after adding in its own via header, to proxy server 210. 
An example of the INVITE message that can be sent from proxy server 208 
1 0 to proxy server 21 0 is as follows: 

1 INVITE 

2 sip:+46706662326@47.114.177.55:50002;user=phoneSIP/2.0 

3 v: SIP/2.0/UDP 47.11 4.1 77.55:50002 

4 v: SIP/2.0/UDP 47.1 14.1 78.1 1 :50001 
15 5 t tel:+46706662326 

6 f: sip:+705990096@47.1 14.178.11:50001 

7 i: a700ff@47.1 14.178.1 1:50001 

8 CSeq: 1 INVITE 

20 In the example INVITE message, line 1 is a header that identifies the 

message as being an INVITE message. The INVITE message sent from 
proxy server 208 to proxy server 210 is the same as the INVITE message 
sent from signaling gateway 204 to proxy server 208 except that proxy 
server 208 adds its own via header to the message. This via header is 

25 illustrated in line 3 of the example message. In line 3, the via header 
includes the IP address and port number of proxy server 208. This via 
header instructs proxy server 210 to send responses to proxy server 208. 

In response to receiving the INVITE message from proxy server 208, 
proxy server 210 performs a database lookup in its database. If the 
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requested data is not present, proxy server 210 can add its own via header 
to the INVITE message and send the INVITE message to another proxy 
server, such as proxy server n, illustrated in Figure 3. Each proxy server 
adds its own via header to the INVITE message before forwarding the 
5 message to the next proxy server. This ensures that the response to the 
INVITE message travels through each proxy server that handled a request 
When the original proxy server receives the response, that proxy server 
forwards the response to SS7/1P gateway 204. Thus, the number of proxy 
servers can be made arbitrarily large and the number is transparent to 

10 SS7/IP gateway 204. 

In this example, it is assumed that proxy server 210 has the data 
requested by the original TCAP query, i.e., the routing number 
corresponding to the ported number. Thus, in line 5 of the call flow diagram, 
proxy server 210 sends a MOVED message to proxy server 208 (which is 

15 the first "via" header from the INVITE message in line 4 of the call flow 
diagram). An example of such a MOVED message is as follows: 



Line 2 of the SIP message includes the via header of proxy server 
208. This header contains the port number and IP address of proxy server 
208 to which the MOVED message is forwarded. The contact field in line 6 
30 of the SIP message contains the contact number obtained from the 



25 



20 



1 

2 
3 
4 
5 
6 
7 
8 



SIP/2.0 302 Moved Temporarily 
v: SIP/2.0/UDP 47.114.177.55:50002 
v: SIP/2.0/UDP 47.114.178.11:50001 
t: tel:+46706662326 

f: sip:+705990096@47.1 14.178.1 1:50001 
m: tel+46701 234567 
i: a700ff@47.1 14.178.1 1:50001 
CSeq: 1 INVITE 
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database lookup. The remaining fields in the SIP message are similar to 
those described with the other SIP messages described above. 

In line 6 of the call flow diagram, proxy server 208 acknowledges 
receipt of the MOVED message. An example of such an acknowledgment is 
5 as follows: 

1 ACKsip:+46706662326@47.114.177.55:50002;user=phone SIP/2 0 

2 v: SIP/2.0/UDP 47.1 14.177.55:50002 

3 v: SIP/2.0/UDP 47.1 14.178.1 1:50001 

4 t: tel:+46706662326 

10 5 f: sip:+705990096@47.1 14.178.1 1:50001 

6 m: tel+46701 234567 

7 i: a700ff@47.1 14.178.1 1:50001 

8 CSeq: 1 ACK 



15 The fields in this SIP message are the same as those described with 

respect to the MOVED message above. Hence a description thereof is not 
repeated herein. 

In line 7 of the call flow diagram, proxy server 208 removes its own 
"via" header and forwards the MOVED message to gateway 204. An 
20 example of such a MOVED message is as follows: 

1 SIP/2.0 302 Moved Temporarily 

2 v: SIP/2.0/UDP 47.1 14.178.1 1:50001 

3 t tei:+46706662326 

4 f: sip:+705990096@47.1 14.1 78.1 1:50001 
25 5 m: tel+46701 234567 

6 i:a700ff@47.114.178.11:50001 

7 CSeq: 1 INVITE 

The only via header remaining in the example MOVED 
30 TEMPORARILY message is the via header of signaling gateway 204. The 
via header of signaling gateway 204 in line 2 of the MOVED message 
described above has been removed. The remaining fields in the example 
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MOVED message are the same as those described above. Hence a 
description thereof is not repeated herein. 

In tine 8 of the call flow diagram. SS7/IP gateway 204 acknowledges 
receipt of the MOVED message. An example of such an acknowledgment is 
5 as follows: 

1 ACKsip:+46706662326@47.1 14.177.55:50002;user=phone SIP/2.0 

2 v: SIP/2.0/UDP 47.114.178.11:50001 

3 t: tel:+46706662326 

4 t sip:+705990096@47.1 14.178.1 1:50001 
10 5 m: tel+46701234567 

6 i: a700ff@47. 1 1 4. 1 78. 1 1 :50001 

7 CSeq: 1 ACK 

In the example ACKNOWLEDGE message, signaling gateway 204 
15 includes its own via header to indicate that responses to the 
ACKNOWLEDGE message are to be sent to signaling gateway 204. This 
via header is illustrated in line 2 of the ACKNOWLEDGE message. The 
remaining fields are the same as those described above with respect to the 
MOVED TEMPORARILY message. Hence a description thereof is not 
20 repeated herein. 

In line 9 of the call flow diagram, SS7/IP gateway 204 extracts the 
contact number from the MOVED message and communicates the number 
to SSP 202 in a TCAP response message. Because SS7/IP gateway 
receives the contact number in the MOVED message from proxy server 206, 
25 the number of levels in the database hierarchy is transparent to SS7/IP 
gateway 204. 

Figure 4 illustrates an example of a number portability database that 
can be accessed by a proxy server according to an embodiment of the 
present invention. In Figure 4, database generally designated 400 includes 
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a plurality of entries for records 400A - 400N. Each entry includes a called 
number field 402 for storing a called number, a contact number field 404 for 
storing a contact number corresponding to the called number, a routing 
prefix field 406 for storing a routing prefix indicating a network associated 
5 with the ported number, a default contact number field 408 for storing default 
contact numbers and an action code field 410 for indicating whether to proxy 
or respond to a request In entry 400A, the called number is 46705990060. 
The contact number field 404 also contains the number 46705990060. 
Because the called number and the contact number are the same, it is 
10 evident that the called number has not been ported. Default contact number 
field 408 in entry 400A also contains the same called number. Action code 
field 410 in entry 400A includes an action code of U V which indicates that the 
proxy server can respond to the request. 

In entry 400B, the number stored in called number field 402 is 
15 different from the contact number field 404. Hence, from this entry it is 
evident that the called number has been ported. Action code field 410 
specifies a "1" which indicates that proxy server 208 can respond to queries 
containing the called number. In entry 400C, there is no contact number 
stored in contact number field 404. In addition, the value in action code field 
20 410 is set to U T indicating that proxy server 208 should proxy any queries 
containing the called number 46706662326. In the event that proxy server 
208 does not receive a response within a predetermined time period, proxy 
server 208 can respond to the request with the default number 46706662326 
specified in default contact number field 408. Examples where it can be 
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desirable to provide a default contact number will be discussed in more 
detail beiow. 

Generic Distributed Database 
Although the example above illustrates the implementation of a real- 
5 time, distributed number portability database, the present invention is not 
limited to such an embodiment. For example, the methods and systems for 
implementing a real-time, distributed, hierarchical database can be suitably 
used to implement any type of database that requires high-speed access to 
a large number of records. Examples of types of databases that the present 

10 invention can be used to implement include home location registers, visitor 
location registers, etc. 

Figure 5 illustrates an arbitrary database structure that can be 
implemented by proxy servers according to an embodiment of the present 
invention. In the illustrated embodiment, master proxy server 500 receives 

15 requests for information from a database. In the illustrated embodiment, 
master proxy server 500 contains a database generally designated 502 in 
which each record is indexed by a letter of the alphabet. In the illustrated 
example, database 502 includes records 502A - 502Z. Each record 502A - 
502Z includes a key field 504 containing a letter of the alphabet. Each 

20 record 502a - 502z also includes a data field 506 containing the address of 
a proxy server to which the second level of the database hierarchy is 
implemented. For example, record 502A includes the letter "A" in key field 
504. Data field 506 includes the address of A proxy server 508A. The 
remaining fields in database 502 contain letters B - Z in key fields 504 and 

25 the addresses of the appropriate proxy server in data fields 506, 
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respectively. Proxy servers 508A - 5082 each include a database 51 OA - 
510Z, respectively. The databases 510A - 5102 provide the second level of 
data for the given database hierarchy. 

In operation, when proxy server 500 receives an INVITE message, 
5 the message can request a database record corresponding to the text string 
"C1234". Proxy server 500 accesses database 502 and locates record 502C 
based on the first letter in the text string. Record 502C includes the address 
of C proxy server 508C. Accordingly, proxy server 500 formulates an 
INVITE message and transmits the INVITE message to C proxy server 
10 508C. The INVITE message can include the same text string as the first 
INVITE message. The INVITE message preferably also includes response 
routing information indicating that responses should be sent to proxy server 
500. When C proxy server 508C receives the INVITE message, C proxy 
server performs a lookup in C database 51 0C using the digits "1234°. If C 
15 proxy server 508C locates a record in C database 510C containing the 
desired information, C proxy server 508C preferably sends a response to 
proxy server 500 containing the desired information. Proxy server 500 can 
then send the information to the requesting entity in the appropriate protocol. 
If C database 51 0C does not contain the data for responding to the 
20 request. C proxy server 508C can proxy the request from proxy server 500 
and query another database at another hierarchical level (not shown). The 
request preferably includes response routing information that indicates that 
responses should be sent to C proxy server 508C. Thus, as illustrated in 
Figure 5, the methods and systems for implementing a real-time, distributed. 
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hierarchical database according to embodiments of the. present invention 
can be extended to arbitrarily complex data structures. 



Response Timer 

5 As stated above, embodiments of the present invention are preferably 

capable of implementing a real-time, distributed, hierarchical database in 
which the number of levels in the hierarchy is transparent to the database 
user. One aspect of transparency is that the database user receives a 
response from the entity from which data was requested. This aspect is 

10 enabled by the proxying capabilities of the underlying protocol. Another 
aspect of transparency is timing. For example, if the first proxy server is 
unable to obtain a response from additional proxy servers in the hierarchical 
chain, the first proxy server preferably sends a default response to the 
database user that is within a time period specified by the database user. 

15 For example, the TCAP protocol provides a maximum response time for 
TCAP messages. Accordingly, when master proxy server 500 illustrated in 
Figure 5 receives an INVITE message based on a TCAP query, master 
proxy server 500 preferably starts a timer and takes appropriate action to 
ensure that a response is sent to the message within the time period. 

20 Figure 6 is a flow chart illustrating exemplary steps that can be 

performed by master proxy server 500 in implementing a response timer 
according to an embodiment of the present invention. In step ST1, master 
proxy server 500 receives an INVITE message from a database user? For 
example, the database user can be an SS7/IP gateway, as illustrated and 

25 described with respect to Figure 2. In step ST2A, in response to receiving 



WO 01/61529 PCT7IB01/0U1»:> 

-20- 

the message, master proxy server 500 starts a response timer. The 
response timer can be set to a value that is less than the permissible time 
period for responding to the request received in step ST1. For example, the 
response timer can be set to 50% of the maximum time period for 
5 responding to the message. In step ST3A, master proxy server 500 reads 
the timer. In step ST4A, proxy server 500 determines whether the timer has 
expired. If the timer has not expired, proxy server 500 can continue to check 
whether the time has expired by repeating steps ST3A and ST4A. 

Simultaneously with starting the response timer, in step ST2B, proxy 
10 server 500 can attempt to obtain the requested data. Attempting to obtain 
the requested data can include accessing a local database and/or sending a 
message to another proxy server. In step ST3B, proxy server 500 
determines whether the requested data has been obtained. If the requested 
data has been obtained in step ST4C, proxy server 500 sends the requested 
15 data to the database user. In step ST3B, if the requested data has not been 
obtained, proxy server 500 continues to attempt to obtain the requested 
data. Steps ST2B and ST3B can be repeated until the timer expires. 

Refenring again to step ST4A, if proxy server 500 determines that the 
time has expired, proxy server 500 preferably sends default data to the 
20 database user (step ST5A). The default data can include all of the data 
obtained up until the timer expired to the database user. For example, proxy 
server 500 can perform a lookup in its local database, and then request 
information from another proxy server in the hierarchy. If the timer expires 
before a reply is received to the request, proxy server 500 preferably sends 
25 the results of the first database lookup to the database user. The results 
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from the local database lookup can be a default response for the query or an 
indication of failure. Thus, proxy server 500 provides real-time responses to 
database users, even when one or more of the proxy servers that implement 
the distributed database failed. 
5 One example of when it can be desirable to provide a default 

response relates to number portability. For example, an end user might 
desire to have calls to his or her home number forwarded to a mobile phone. 
In this case, the user's mobile phone number can be stored in the contact 
field of a number portability database, for example, as illustrated in Figure 4. 

10 The contact information can be modified by an end user via a web browser. 
Thus, a first level number portability database for the end user might contain 
the user's home number in the default contact number field, but indicate that 
a request should be proxied. A second level number portability database 
can contain the user's mobile phone number in the contact number field, as 

15 dynamically configured by the end user. When a query arrives at the first 
level database, the first level database proxies the query to the second level 
database. If the proxy server managing the first database does not receive a 
response before the timer expires, the proxy server can supply the user's 
home number as a default response. 

20 It will be understood that various details of the invention can be 

changed without departing from the scope of the invention. Furthermore, the 
foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation — the invention being defined by the claims. 
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CLA1MS 

What is claimed is: 

1. A system for implementing a real-time, distributed, hierarchical 
database using a proxiable protocol, the system comprising: 
5 (a) a first proxy server for receiving, from a first network element, a 

first proxiable protocol message including first response routing 
information for routing a response to the first message to the 
first network element, performing a first database lookup based 
on information contained in the first message, formulating a 
10 second proxiable protocol message including second response 

routing information for routing a response to second message 
to the first proxy server based on results from the first database 
lookup, and sending the second message over a network; and 
(b) a second proxy server for receiving the second message, and, 
15 in response, performing a second database lookup based on 

information contained in the second message, formulating a 
third proxiable protocol message including the first and second 
response routing information based on results from the second 
database lookup, and sending the third message to the first 
20 proxy server based on the second response routing 

information. 



2. The system of claim 1 wherein the first proxy server receives the third 
message, and, in response, transmits a fourth proxiable protocol 
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message to the first network element based on the first response 
routing information. 



3. The system of claim 2 wherein the first, second, third, and fourth 
5 messages are session initiation protocol (SIP) messages. 

4. The system of claim 3 wherein the first and second messages are SIP 
INVITE messages and the third and fourth messages are SIP 
MOVED messages. 

10 

5. The system of claim 3 wherein the first response routing information 
includes a first via header including an address of the first network 
element and the second response routing information includes a 
second via header including an address of the first proxy server. 

15 

6. The system of claim 1 wherein the first proxy and second proxy 
servers are session initiation protocol (SIP) proxy servers. 



7. The system of claim 1 wherein the first proxy server includes a timer, 
20 and, in response to failing to receive the third message from the 

second proxy server before the timer expires, the first proxy server 
formulates a fourth proxiable protocol message and forwards the 
fourth message to the first network element. 
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8. The system of claim 7 wherein the fourth message includes the 
results from the first database lookup. 



9. The system of claim 1 wherein the first message contains a called 
5 party number, the first proxy server is adapted to perform the first 

database lookup using the called party number as a key to determine 
location information for the second proxy server, and the second 
proxy server is adapted to perform the second database lookup using 
the called party number to determine a contact number corresponding 
10 to the called party number. 

10. A method for using a proxiable protocol to implement a real-time, 
distributed, hierarchical database, the method comprising: 
at a first proxy server, 
15 (3) receiving, from a first network element, a first proxiable 

protocol message including first response routing information 
for routing responses to the first message to the first network 
element; 

(b) performing a first database lookup based on information 
20 contained in the first message; 

(c) formulating a second proxiable protocol message based on 
results from the first database lookup; 

(d) adding second response routing information to the second 
message for routing responses to the second message to the 

25 first proxy server; 
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(e) sending the second message to a second proxy server; 
at the second proxy server. 

(f) receiving the second message, and, in response, performing a 
second database lookup based on information contained in the 

5 second message; 

(g) formulating a third proxiable protocol message based on 
results from the second database lookup, the third message 
including the first and second response routing information; 
and 

10 (h) transmitting the third message to the first proxy server based 

on the second response information. 



11. The method of claim 10, comprising, at the first proxy server, 
receiving the third message, and, in response, transmitting, to the first 

1 5 network element, a fourth proxiable protocol message based on the 

first response routing information. 

12. The method of claim 11 wherein formulating the first, second, third, 
and fourth messages includes formulating session initiation protocol 

20 (SIP) messages. 

13. The method of claim 12 wherein formulating the first and second 
messages includes formulating SIP INVITE messages and 
formulating the third and fourth messages included formulating SIP 

25 MOVED messages. 
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10 



14. The method of claim 12 wherein the first response routing information 
includes a first via header having an address for the first network 
element and the second response routing information includes a 
second via header having an address for the first proxy server. 

15. The method of claim 10 wherein receiving the first message at a first 
proxy server includes receiving the first message at a session 
initiation protocol (SIP) proxy server. 

16. The method of claim 10 wherein receiving the second message 
includes receiving the second message at a session initiation protocol 
(SIP) proxy server. 



15 17. The method of claim 10 comprising, at the first proxy server, in 
response to sending the second message, starting a timer, and, in 
response to failing to receive the third message from the second 
proxy server before the timer expires, formulating a fourth proxiable 
protocol message and forwarding the fourth message to the first 

20 network element. 

18. The method of claim 17 wherein formulating the fourth message 
includes placing the results from the first database lookup in the fourth 
message. 

25 
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19. The method of claim 10 wherein the first message contains a called 
party number, performing the first database lookup includes 
performing the first database lookup using the called party number to 
determine location information for the second proxy server, and 

5 performing the second database lookup includes performing the 

second database lookup using the called party number. 

20. The method of claim 19 wherein the called party number is a ported 
number and the results from the second database lookup include a 

10 contact number corresponding to the ported number. 

21. A method for implementing a real-time, distributed, hierarchical 
database, the method comprising: 

(a) receiving a first proxiable protocol message from a database 
15 user; 

(b) starting a timer: 

(c) attempting to obtain information requested by the first 
message; and 

(d) in response to determining that the timer has expired, sending 
20 a response to the database user, the response containing 

information obtained prior to expiration of the timer. 



25 



22. 



The method of claim 21 wherein attempting to obtain the information 
requested by the first message includes performing a lookup in a first 
database accessible by the first proxy server and obtaining a first 
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portion of the Information requested, formulating a second proxiable 
protocol message, and sending the second message to a second 
proxy server to obtain a second portion of the information requested. 

5 23. The method of claim 21 wherein, when the timer expires after 
obtaining the first portion of the information and prior to obtaining the 
second portion requested, sending a reply containing the first portion 
of the information requested to the database user. 



10 24. The method of claim 22 wherein formulating the second message 
includes formulating a session initiation protocol (SIP) message. 

25. The method of claim 24 wherein formulating a SIP message includes 
formulating a SIP INVITE message. 



15 



26. The method of claim 22 wherein receiving the first message includes 
receiving a first message including first response routing information 
specifying a return path for responses to the first message and 
formulating the second message includes including second response 
20 routing information specifying a return path for responses to the 

second message. 



27. 



The method of claim 26 wherein the first response routing information 
includes an address for a sender of the first message and the second 
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response routing information includes an address for the first proxy 
server. 



28. A computer program product comprising computer-executable 
5 instructions embodied in a computer-executable medium for 

performing steps comprising: 

(a) at a first proxy server, receiving, from a first network element, a 
first proxiable protocol message including first response routing 
information for routing responses to the first message to the 

1 0 first network element; 

(b) performing a first database lookup based on information 
contained in the first message; 

(c) formulating a second proxiable protocol message based on 
results from the first database lookup; 

15 (d) adding second response routing information to the second 

message for routing responses to the second message to the 
first proxy server; 

(e) receiving a response to the second message, the response 
including the first and second response routing information; 

20 and 

(f) forwarding the response to the first network element based on 
the first response routing information. 



29. 

25 



The computer program product of claim 28 wherein receiving the first 
message includes receiving a first session initiation protocol (SIP) 
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message and formulating the second message includes formulating a 
second SIP message. 

30. The computer program product of claim 29 wherein the first response 
5 routing information includes an address for the first network element 

and the second response routing information includes an IP address 
for the first proxy server. 



10 
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